Server to network signaling method for rapid switching between anycast multicast sources

ABSTRACT

Described embodiments of the present invention use a simplified signaling mechanism in a server to signal the status of the individual multicast source streams.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to networking and, more specifically, to amethod and system for reliably transmitting IPmc streams of data over anetwork.

2. Description of the Background Art

While the concept of anycasting is well known, it is most often appliedto services where unicast traffic is sent towards an anycast address asa form of redundancy for a service. When IP (Internet Protocol)multicast is used, it is also feasible to source IP multicast trafficfrom an anycast address to provide server redundancy. Currentimplementations have some limitations. For example, assume that two ormore servers at separate physical locations in a network source the samecontent. Both servers are assigned the same IP address. A local routerfor each of the servers is configured to advertise this address to thenetwork as a host route so that clients in the network will connect tothe nearest anycast server. One use of anycast servers is to sourcevideo data. Anycast multicast video servers in video networks provideboth load balancing and redundancy. For example, some video serversreceive multiple MPEG ASI video streams that are packetized intoseparate multicast streams. The servers then send the data as multicastto a destination by way of network routers.

Sometimes, a server will not transmit one or more of its data streamsdue to loss of input signal to the server. In conventional systems, ifonly a single data stream from a server goes down (e.g., an MPEG videostream) while all other streams from the server remain up, there is noway to restore the lost single stream, short of manually switching toanother server that has all streams up. In this situation, the physicalconnection between the anycast server and the router has not gone down.The router is sending some legitimate streams of data; it is just notsending all of its streams. Conventional systems determine that a serveris unavailable and not sending by looking at the physical interfacebetween the server and the router. Unfortunately, because the physicalinterface between the anycast server and the router has not gone down,the router will not be able to detect a loss of physical connection andwithdraw the host route from the network.

Sometimes a physical connection between a server and a router goes down.If the router connects to the server through switch interfaces, therouter will be unaware that the physical link from the server to theswitch has gone down. The actual application on the server appliancegenerating one or more video streams may be incapable of generating alink up/down signaling on its interface.

What is needed is some way for the routers to determine when some butnot all streams from a server have gone down so that the router canwithdraw the associated anycast host route from the network and forcethe network to switch to a remaining anycast source in the network.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is illustrated by way of example, and not by way oflimitation in the figures of the accompanying drawings in which likereference numerals refer to similar elements.

FIG. 1 is a block diagram in accordance with a preferred embodiment ofthe present invention when no streams are down.

FIG. 2 is a block diagram in accordance with a preferred embodiment ofthe present invention when at least one stream is down.

FIGS. 3(a) and 3(b) are flow charts performed by a server in accordancewith a preferred embodiment of the present invention.

FIG. 3(c) is a flow chart performed by a server in accordance with apreferred embodiment of the present invention.

FIG. 4 shows a packet format in accordance with a preferred embodimentof the present invention.

FIG. 5 is a block diagram in accordance with another preferredembodiment of the present invention when at least one stream is down.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Described embodiments of the present invention use a simplifiedsignaling mechanism in the anycast server (and/or a management station)to signal the status of the individual multicast source streams. Theanycast server periodically sends status information advertising a hostroute for each source stream that the server is “actively” sourcing. Apreferred embodiment of the invention uses the Routing InformationProtocol (RIP) to advertise host routes for each multicast sourcealthough other routing protocols could be used. A recipient joins amulticast stream using known methods, causing Join messages to be senttowards the nearest source following the path described by IGP routinginformation. This causes the stream from the nearest appropriate serverto be routed to that recipient. For example, if an anycast video serveris sourcing twenty-four flows as source IP addresses S1-S24 to one ormore multicast groups, the server would construct status informationwith twenty-four host routes, S1/32 through S24/32 with the first metricfor each stream. The router is configured to redistribute these hostadvertisements into a rapid converging IGP (Internet Gateway Protocol)routing protocol (e.g. OSPF, EIGRP or ISIS) being used in the network.

If the anycast server detects the loss of any of its data streams (e.g.,loss of MPEG video in the case of a video anycast server), itimmediately triggers new status information that withdraws thepreviously advertised host route. In the preferred embodiment of theinvention using the Routing Information Protocol (RIP), the host routeassociated with the affected source address is withdrawn by advertisingthe source address with a RIP metric of “infinity” (16 hops). Thisresults in the router withdrawing this host route from the IGP causingthe network to converge to the remaining anycast server(s) in thenetwork.

It is also possible for a third-party network management station toperform the signaling based on other out of band telemetry between theserver and the network management station. This method is capable ofbeing applied not only to an “anycast” announcement, where allannouncements have the same priority, but also by simply using differentprefix-length to a priority-based announcement scheme.

FIG. 1 is a block diagram in accordance with a preferred embodiment ofthe present invention when no streams are down. FIG. 1 shows a firstserver 102 (in this example, located in San Francisco, SF). Server 102receives multiple data streams 120 (e.g., twenty-four data streams) andsends the streams in packetized form to a router 106 via a network 101.Router 106 routes the packets to an ultimate destination via network101. Server 102 further transmits status information 103, showingwhether each of the streams 120 is up. FIG. 1 also shows a second server104 (in this example, located in New York, N.Y.). Server 104 receivestwenty-four data streams 122 and sends the streams in packetized form toa router 110 via a network 101, such as the Internet, an intranet, or anextranet. The network can transmit packets via a wired or wirelessconnection. Server 104 further transmits status information 105, showingwhether each of the streams 122 is up.

Router 106 transmits routing information 107, as is known in the art toindicate that router 106 is on the routes to server 102 to obtain eachof streams 120. In the example, all streams are up and router 106transmits routing information 107 for each of streams 120. Router 110transmits routing information 111, as is known in the art to indicatethat router 110 is on the routes to server 104 to obtain each of streams122. In the example, all streams are up and router 110 transmits routinginformation 111 for each of streams 122.

As is understood by persons of ordinary skill in the art, in a preferredembodiment, new potential receivers of streams are connected to thesource stream by the use of a PIM (Protocol Independent Multicast)protocol, and existing IGP routing information in the routers, to sendPIM Join messages towards a source to establish a flow of data to thereceivers.

The system of FIG. 1 can be implemented as redundant data sources (e.g.,redundant heads ends of a video cable system). In a describedembodiment, multiple head ends source a stream. For example, two headends might source a particular stream. Thus, if one head end goes offthe air, then the other head end will continue sourcing the stream. Thereceivers will be connected to the nearest source via PIM Join messageswhich follow the path to the source based on the routing metrics (suchas IGP metrics) in the network.

Alternately, the servers might each serve a different geographical areawhen both servers are up, with one server beginning to source a streamfor all recipients if that stream goes down on the other server. Inother embodiments, servers 102 and 104 are co-located instead of beinggeographically dispersed. In some embodiments, servers 102 and 104 serveas backup for each other for at least some of their streams. The systemof FIG. 1 can be used to transport any type of redundant data streams,including but not limited to video data (such as digital SGI data, MPEGdata), audio data, redundant market information (stock ticker),redundant MMPG world updates (massive multiplayer games), redundanttelemetry, redundant multicast for software updates, and so on.

Streams may go down for any of a large number of reasons. A physicalconnection may have been severed. A logical or business connection mayhave failed. A satellite connection may have failed.

FIG. 2 is a block diagram in accordance with a preferred embodiment ofthe present invention when at least one stream is down at first server102 and up at second server 104. In this example, stream 121, which isinput to server 102, is down. Stream 121′, which is input to server 104,is up. When server 102 detects that stream 121 is down, it sends statusinformation 103 indicating that stream 121 (stream S2) is down but thatall other streams sourced from server 102 are up. In accordance with thereceived information, router 106 changes the routing information 107 toremove itself from the route to stream S2 121 by withdrawing the hostroute to S2 121. The router information for stream 121′ of router 104does not change. Therefore, routing information in network 101 forstream S2 121 will quickly converge so that requests for stream S2 121are routed to server 104 and not to server 102.

FIGS. 3(a) and 3(b) are flow charts of a method performed by a server inaccordance with a preferred embodiment of the present invention. In FIG.3(a), when a stream is down 304, server 102, 104 sends 306 a statuspacket to the routers to so indicate. Server 102, 104 checks each of itsstreams in turn 302. In FIG. 3(b), server 102, 104 periodically checkseach of its streams to determine whether a status of the stream haschanged. In FIG. 3(b), server 102, 104 periodically 324 sends the statusof its streams to the routers 326. In a preferred embodiment, theperiodicity is every 30 seconds.

FIG. 3(c) is a flowchart of a method performed by each of router 106,110 in accordance with a preferred embodiment of the present invention.Router receives 352 a status for each steam from one of the servers (orNMS). If a stream is down 354, router 106, 110 communicates with otherrouters in network 101 to reroute requests for the stream that is downaway from the server having the down stream. In a preferred embodiment,this is done by having router 106 advertise routes for each stream inaccordance with which stream at which server is up. (i.e., the routerwithdraws a host route from the IGP causing the network to converge tothe remaining anycast server(s) in the network).

FIG. 4 shows a packet format for the status information sent from aserver (or NMS) in accordance with a preferred embodiment of the presentinvention. The status information acts as a signaling mechanism thatallows a server to indicate which of its streams is up and which isdown. In the described embodiment, a status packet contains the statusof each stream. Other embodiments may contain statuses of a subset ofthe streams. In the described embodiment, the status packet is based onthe RIPv2 Response packet, as described in RFC 2453, “RIP version 2,” G.Malkin, 1998, which is incorporated herein in its entirety. RIP is anexample of a distance-based protocol. Note that the described embodimentdoes not implement the entire RIP protocol, although other embodimentsmay do so.

Packet 402 contains a status for each stream sent by a server (here RIPentries 1-24). Each status has a value of either “up” or “down” in field408. Other embodiments may incorporate additional or other appropriatestatus values. In the described embodiment, a status of “up” isindicated by a value of “1” in field 408 and a status of “down” isindicated by a value of “16” in field 408. The next-hop address in field406 may be fine-tuned by setting field 406 to have the same content asfield 410 (IP source address announced).

In the example of FIGS. 1 and 2, a video server 102 is sourcingtwenty-four streams as source IP addresses S1-S24 to one or moremulticast groups. Recipients have joined these groups using, forexample, a multicast Join message. Periodically (or when a statuschanges) the server constructs a standard RIPv2 response packet withtwenty-four host routes, S1/32 through S24/32 with a metric of “1” infield 408. The status packet contains a separate source IP address 410for each stream being sourced by a server.

The router receives the packet and is configured to distribute theseRIPv2 host advertisements into a rapidly converging IGP route protocol(e.g., OSPF, EIGRP or ISIS protocols). If the server detects the loss(or recovery) of any of its data streams (e.g., loss of MPEG video inthe case of a video anycast server), it will immediately trigger a newRIPv2 Response packet with the affected stream advertised with a metricof “infinity” (i.e., 16). This results in the router withdrawing thishost route, causing the network to converge to the remaining anycastservers that source the stream that has gone down.

In a preferred embodiment, a newer version of network protocol (such asISIS, EGRP, or OSPF) connects to a network running RIP at its boundary.In such as situation, RIP routing information indicating source statuswill need to be redistributed into the network's IGP. As understood bypersons of ordinary skill in the art, the system can be configured toperform this function.

FIG. 5 is a block diagram in accordance with another preferredembodiment of the present invention when at least one stream is down. Inthis embodiment, third party network management stations (NMS) 502, 504perform the status signaling based on out of band telemetry between theserver and its network management station. In other words, when loss ofa telemetry signal between NMS and its associated server is detected,the NMS indicates that a stream is down, as described above. Theadvantage of using an NMS is that it allows the introduction of theredundancy and fast failover offered by this invention withoutnecessarily having to upgrade the actual servers sending the traffic. AnNMS can detect streamer failure and send the down signal for all streamsthat were being transmitted by the streamer to the router. However, theuse of a NMS can add latency to the detection and signaling of the lossof a single stream. Combinations of both streamer signaling and NMSsignaling are possible.

In summary, sending status information sent from the server to its localrouter allows control to be implemented in the server (or third partymanager).

Reference in the specification to “one embodiment,” “certainembodiments” or “an embodiment” means that a particular feature,structure, or characteristic described in connection with the embodimentis included in at least one embodiment of the invention. The appearancesof the phrase “in one embodiment” in various places in the specificationare not necessarily all referring to the same embodiment.

Some portions of the detailed descriptions are presented in terms ofmethods and symbolic representations of operations on data bits within acomputer memory in a router and/or a source. These methodic descriptionsand representations are the method used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. A method is here, and generally, conceivedto be a self-consistent sequence of steps leading to a desired result.The steps are those requiring physical manipulations of physicalquantities. Often, though not necessarily, these quantities take theform of electrical or magnetic signals capable of being stored,transferred, combined, compared, and otherwise manipulated. It hasproven convenient at times, principally for reasons of common usage, torefer to these signals as bits, values, elements, symbols, characters,terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the following discussion,it is appreciated that throughout the description, discussions utilizingterms such as “processing” or “computing” or “calculating” or“determining” or “displaying” or the like, refer to the action andprocesses of a computer system, or similar electronic computing device,that manipulates and transforms data represented as physical(electronic) quantities within the computer system's registers andmemories into other data similarly represented as physical quantitieswithin the computer system memories or registers or other suchinformation storage, transmission or display devices.

The present invention also relates to apparatus for performing theoperations herein. This apparatus may be specially constructed for therequired purposes, or it may comprise a general-purpose computerselectively activated or reconfigured by a computer program stored inthe computer. Such a computer program may be stored in a computerreadable storage medium, such as, but is not limited to, any type ofdisk including floppy disks, optical disks, CD-ROMs, andmagnetic-optical disks, read-only memories (ROMs), random accessmemories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any typeof media suitable for storing electronic instructions, and each coupledto a computer system bus.

The methods and displays presented herein are not inherently related toany particular computer or other apparatus. Various general-purposesystems may be used with programs in accordance with the teachingsherein, or it may prove convenient to construct more specializedapparatus to perform the required method steps. The required structurefor a variety of these systems will appear from the description below.In addition, the present invention is not described with reference toany particular programming language. It will be appreciated that avariety of programming languages may be used to implement the teachingsof the invention as described herein.

Moreover, the present invention is claimed below operating on or workingin conjunction with an information system. Such an information system asclaimed may be the entire messaging system as detailed below in thepreferred embodiment or only portions of such a system. Thus, thepresent invention is capable of operating with any information systemfrom those with minimal functionality to those providing all thefunctionality disclosed herein.

While the present invention has been described with reference to certainpreferred embodiments, those skilled in the art will recognize thatvarious modifications may be provided. Variations upon and modificationsto the preferred embodiments are provided for by the present invention,which is limited only by the following claims.

1. A method, comprising: receiving multiple streams of data and sourcingthe multiple streams of data to a recipient; and periodically sendingstatus information for each of the multiple streams of data to therecipient indicating whether each of the multiple streams of data is upor down.
 2. The method of claim 1, further comprising: determining whenone of the multiple streams of data is down; and in accordance with thedetermining, sending status information for the multiple streams of datato the recipient indicating that one of the multiple streams of data isdown.
 3. The method of claim 1, wherein the multiple streams of data aremultiple streams of video data.
 4. The method of claim 1, wherein thestatus information includes a separate IP source address for each of themultiple streams of data.
 5. The method of claim 1,wherein the statusinformation includes a “1” value when one of the multiple data streamsis up.
 6. The method of claim 1, wherein the status information includesan “infinity” value when one of the multiple data streams is down. 7.The method of claim 1, wherein the recipient is a router.
 8. The methodof claim 1, wherein the recipient is an Internet router.
 9. The methodof claim 7, wherein the router sends routing information to anotherrouter to remove a route to the server for one of the multiple streamsof data when the stream of data is down at the server.
 10. The method ofclaim 7, wherein the router sends routing information to another routerto add a route to a second server for one of the multiple streams ofdata when the multiple route of data is down at a first server.
 11. Themethod of claim 1, wherein sending status information is performed by aserver.
 12. The method of claim 1, wherein sending status information isperformed by a network management station separate from a server that issourcing the multiple streams of data.
 13. The method of claim 1,wherein the status information is sent using a distance-based routingprotocol.
 14. The method of claim 1, wherein the status information issent using a RIP protocol.
 15. A method, comprising: receiving multiplestreams of data from a source; and periodically receiving statusinformation for each of the multiple streams of data from the source,indicating whether each of the multiple streams of data is up or down.16. The method of claim 15, further comprising: where the method isperformed by a router and, in accordance with receiving the statusinformation indicating that a particular stream of data is down, sendingrouting information to another router to remove a route to the source ofthe particular stream of data.
 17. The method of claim 15, wherein themultiple streams of data are multiple streams of video data.
 18. Themethod of claim 15, wherein the status information includes a separateIP source address for each of the multiple streams of data.
 19. Themethod of claim 15, wherein the status information includes a “1” valuewhen one of the multiple data streams is up.
 20. The method of claim 15,wherein the status information includes an “infinity” value when one ofthe multiple data streams is down.
 21. The method of claim 15, whereinthe method is performed by a router.
 22. The method of claim 15, whereinthe method is performed by an Internet router.
 23. The method of claim15, wherein sending status information is performed by a server.
 24. Themethod of claim 15, wherein sending status information is performed by anetwork management station separate from a server that is sourcing themultiple streams of data.
 25. The method of claim 15, wherein the statusinformation is sent using a distance-based routing protocol.
 26. Themethod of claim 15, wherein the status information is sent using a RIPprotocol.
 27. A system, comprising: a module that receives the multiplestreams of data and sources the multiple streams of data to a recipient;and a module that periodically sends status information for each of themultiple streams of data to the recipient indicating whether each of themultiple streams of data is up or down.
 28. The system of claim 27,further comprising: a module that determines when one of the multiplestreams of data is down; and a module that sends, in accordance with thedetermining, status information for the multiple streams of data to therecipient indicating that one of the multiple streams of data is down.29. A system, comprising: a module that receives multiple streams ofdata from a source; and a module that periodically receives statusinformation for each of the multiple streams of data from the source,indicating whether each of the multiple streams of data is up or down.30. The system of claim 29, further comprising: where the system is arouter and a module that sends, in accordance with receiving the statusinformation indicating that a particular stream of data is down, routinginformation to another router to remove a route to the source of theparticular stream of data.
 31. An apparatus, comprising: means forreceiving multiple streams of data and sourcing the multiple streams ofdata to a recipient; and means for periodically sending statusinformation for each of the multiple streams of data to the recipientindicating whether each of the multiple streams of data is up or down.32. An apparatus, comprising: means for receiving multiple streams ofdata from a source; and means for periodically receiving statusinformation for each of the multiple streams of data from the source,indicating whether each of the multiple streams of data is up or down.33. A computer program product, having a computer readable medium havinginstructions thereon capable of causing a data processing system toperform a method comprising: receiving multiple streams of data andsourcing the multiple streams of data to a recipient; and periodicallysending status information for each of the multiple streams of data tothe recipient indicating whether each of the multiple streams of data isup or down.
 34. A computer program product, having a computer readablemedium having instructions thereon capable of causing a data processingsystem to perform a method comprising: receiving multiple streams ofdata from a source; and periodically receiving status information foreach of the multiple streams of data from the source, indicating whethereach of the multiple streams of data is up or down.